Expose sandbox properties via IPC JSON, criteria, title format #8521

jacobmcnamee · 2025-01-04T08:42:02Z

Rebase and update of #7187.

Add sandbox properties to IPC JSON, criteria, and title format:

sandbox_engine
sandbox_app_id
sandbox_instance_id

These properties may be set by sandbox engines (e.g. flatpak) via the security context protocol: https://wayland.app/protocols/security-context-v1.

Example Usage

Prepend sandbox properties to window title when sandbox engine is set:

for_window [sandbox_engine="."] title_format "[%sandbox_engine/%sandbox_app_id/%sandbox_instance_id] %title"

Testing

Launch an app via flatpak:

flatpak run org.gnome.clocks

Observe JSON layout tree via swaymsg -r -t get_tree:

"name": "Clocks",
"pid": 14309,
"app_id": "org.gnome.clocks",
...
"sandbox_engine": "org.flatpak",
"sandbox_app_id": "org.gnome.clocks",
"sandbox_instance_id": "2307446143",

Observe pretty layout tree via swaymsg -p -t get_tree:

#1: root "root"
  #2147483647: output "__i3"
    #2147483646: workspace "__i3_scratch"
  #3: output "WL-1"
    #4: workspace "1"
      #5: con "Clocks" (xdg_shell, pid: 14309, app_id: "org.gnome.clocks", sandbox_engine: "org.flatpak", sandbox_app_id: "org.gnome.clocks", sandbox_instance_id: "2307446143")

Observe window title when configured as shown above:

[org.flatpak/org.gnome.clocks/2307446143] Clocks

sway/desktop/xdg_shell.c

sway/ipc-json.c

emersion · 2025-01-08T21:48:04Z

sway/sway.5.scd

+	If the value is \_\_focused\_\_, then the sandbox engine must be the same as
+	that of the currently focused window.
+
+*sandbox_app_id*


I'm kind of wondering whether we should expose this, or whether we should always prefer the sandbox-provided app ID over the one provided by the sandboxed client.

(IIRC GNOME allows org.libreoffice.Writer if the sandbox app ID is org.libreoffice.)

The sandbox app_id is defined to be engine-specific and may have an entirely different meaning.

For example, consider a system container (Docker, LXC, etc.) where the wayland socket / security context is associated with more than one application:

sandbox_engine = "org.docker"

sandbox_app_id = "my-docker-container-2"

app_id = multiple, different per application

I'm not sure even that "Flatpak application ID" is equivalent to app_id (for that specific engine).

See #8521 (comment)

That's a good point! Perhaps one could argue that any sandbox engine sending metadata through the security-context protocol is Wayland-aware (because it has to add support for that specific protocol)? Docker/LXC don't support Wayland apps out-of-the-box, so will not provide these app IDs which don't match xdg-shell. However, as you said nothing prevents a sandbox engine from having a completely different scheme for app IDs.

My main point is that there exist use cases where a single wayland socket / security context must support multiple arbitrary applications, making it impossible to set sandbox_app_id (a single value for the security context and all associated views) in a way which is compatible with app_id (potentially different per view).

For example, a system-level container (e.g. docker run 'my-ubuntu-container-3') could start a terminal, browser, and media player via a single wayland socket / security context.

Flatpak (and other application-level container tools) are a special case where only one application is expected to be associated with a given security context (but again, I'm not sure that's completely accurate).

System-level containers are less secure than per-app containers, because granted permissions apply to the whole container. That is, if a sandboxed app obtains a permission, all other apps in the container can abuse it.

But yeah, indeed, we don't want to prevent one from running containers with multiple apps in it.

emersion

On the whole this looks good to me, added a few comments!

(Thanks for rebasing on top of my criteria changes!)

jacobmcnamee · 2025-01-12T09:20:14Z

I was curious how other compositors are using and/or exposing security context metadata and did some research.

Naming Convention

I think sandbox_ is reasonable because restrictions imposed on a client by the compositor are trivially defeated unless the client is sandboxed (via Flatpak, Docker, LXC, etc.)
I have found little to no conflicting precedent (see research below)

Metadata Usage

Per the protocol spec, app_id and instance_id are "opaque, sandbox-specific identifiers" with any meaning derived from engines.md
Using app_id or instance_id without matching a well-known sandbox_engine violates the spec
Consider system container use cases (e.g. Docker, LXC) where a security context applies to more than one application and app_id may be the name of the container (e.g. "docker-work-3")
References:
- https://wayland.app/protocols/security-context-v1
- https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/staging/security-context/engines.md

Research Summary

Most compositors restrict protocol access for clients with a security context
Most compositors never use security context metadata (sandbox_engine, app_id, instance_id) directly or expose them externally
KWin uses app_id regardless of sandbox_engine for .desktop file lookup (conflicts with spec)
Mutter (draft PR) exposes app_id via existing API function meta_window_get_sandboxed_app_id() when sandbox_engine is "flatpak" (respects spec / engines.md)
PipeWire suggests setting analogous security context properties on objects: pipewire.sec.engine, pipewire.sec.app-id, pipewire.sec.instance-id

Notes and References

COSMIC

restricts protocol access for clients with a security context
references:

Hyprland

restricts protocol access for clients with a security context
references:
- hyprwm/Hyprland@da86aac

Jay

restricts protocol access for clients with a security context
per-protocol permission flags implemented internally, not yet accessible
references:
- wayland: implement wp-security-manager-v1 mahkoh/jay#180

KWin

requires sandbox_engine and app_id to be non-empty (conflicts with spec)
uses app_id regardless of sandbox_engine to find a .desktop file which may contain X-KDE-Wayland-Interfaces= (conflicts with spec)
references:

mutter

draft PR:
- requires sandbox_engine to be set
- exposes app_id via existing API function meta_window_get_sandboxed_app_id() when sandbox_engine is "flatpak" (respects spec / engines.md)
references:
- https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3107
- https://gnome.pages.gitlab.gnome.org/mutter/meta/method.Window.get_sandboxed_app_id.html

niri

restricts protocol access for clients with a security context
references:
- YaLTeR/niri@e4643c6
- Security Context protocol Smithay/smithay#1106

PipeWire

implements an analogous security context interface
suggests setting security context properties on objects: pipewire.sec.engine, pipewire.sec.app-id, pipewire.sec.instance-id
references:
- https://docs.pipewire.org/group__pw__security__context.html
- https://docs.pipewire.org/page_man_pw-container_1.html

emersion

Thanks a lot for doing the research!

This LGTM, will wait for a bit before merging just in case somebody else has objections.

emersion · 2025-01-13T07:54:31Z

Thanks!

jacobmcnamee force-pushed the sandbox_properties branch from 270600d to f4af2ca Compare January 8, 2025 09:58

emersion reviewed Jan 8, 2025

View reviewed changes

sway/desktop/xdg_shell.c Outdated Show resolved Hide resolved

emersion reviewed Jan 8, 2025

View reviewed changes

sway/ipc-json.c Show resolved Hide resolved

emersion reviewed Jan 8, 2025

View reviewed changes

jacobmcnamee and others added 5 commits January 12, 2025 02:04

tree/view: add getters for sandbox properties

87f7bce

ipc-json: add sandbox properties to view JSON

11a8a7e

criteria: add sandbox properties

db44adc

tree/container: support sandbox properties in title format

f469f79

swaymsg: pretty-print sandbox properties

69b4a1a

jacobmcnamee force-pushed the sandbox_properties branch from f4af2ca to 69b4a1a Compare January 12, 2025 10:04

emersion approved these changes Jan 12, 2025

View reviewed changes

emersion merged commit 0b08dce into swaywm:master Jan 13, 2025
3 checks passed

emersion mentioned this pull request Jan 19, 2025

Security context based criteria #7187

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Expose sandbox properties via IPC JSON, criteria, title format #8521

Expose sandbox properties via IPC JSON, criteria, title format #8521

jacobmcnamee commented Jan 4, 2025

emersion Jan 8, 2025

jacobmcnamee Jan 12, 2025

emersion Jan 12, 2025

jacobmcnamee Jan 12, 2025

emersion Jan 13, 2025 •

edited

Loading

emersion left a comment

jacobmcnamee commented Jan 12, 2025 •

edited

Loading

COSMIC

Hyprland

Jay

KWin

mutter

niri

PipeWire

emersion left a comment

emersion commented Jan 13, 2025

Expose sandbox properties via IPC JSON, criteria, title format #8521

Expose sandbox properties via IPC JSON, criteria, title format #8521

Conversation

jacobmcnamee commented Jan 4, 2025

Example Usage

Testing

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emersion Jan 13, 2025 • edited Loading

Choose a reason for hiding this comment

emersion left a comment

Choose a reason for hiding this comment

jacobmcnamee commented Jan 12, 2025 • edited Loading

Naming Convention

Metadata Usage

Research Summary

emersion left a comment

Choose a reason for hiding this comment

emersion commented Jan 13, 2025

emersion Jan 13, 2025 •

edited

Loading

jacobmcnamee commented Jan 12, 2025 •

edited

Loading